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Abstract 

Multipurpose  Activity  Definitions  and  Interfaces  to  Support  Operational  Needs  (MADISON)  is  a 
proposed  operator-oriented  approach  to  Battle-Management/Command  and  Control, 
Communications,  Computing,  Intelligence,  Surveillance,  and  Reconnaissance/Navigation 
(BM/C4ISR/N).  MADISON  responds  to  several  challenges  within  this  broad  domain: 
coordinating  independent,  in-service  systems  to  support  complex  operations;  interoperability; 
operator  training  and  operational  effectiveness;  and,  efficient  resource  allocation.  MADISON  is 
neither  “platform-centric”  nor  “network-centric;”  it  is  “operator-centric,”  intended  to  position  the 
operator  to  fight  the  battle  rather  than  fight  the  system. 

1 .  Introduction 

The  United  States  Navy  (USN)  inventory  contains  a  variety  of  independent  (“stovepipe”)  systems 
in  the  Battle-Management/Command,  Control,  Communications,  Computing,  Intelligence, 
Surveillance,  and  Reconnaissance/Navigation  (BM/C4ISR/N)  domain.  This  situation  carries 
several  disadvantages:  the  high  cost  of  maintaining  separate  program  offices,  hardware,  software, 
documentation,  and  configuration,  maintenance,  and  training  procedures;  lack  of  interoperability; 
and  severe  challenges  to  operators  to  use  the  right  system  at  the  right  time  and  to  switch  back  and 
forth  among  systems  effectively. 

The  USN  has  heavy  investments  in  shipboard  communications  systems  (such  as  the  Automated 
Digital  Network  System1),  satellite  communications  (SATCOM)  systems  (such  as  the  Joint 
(UHF)  MILSATCOM  Network  Integrated  Control  System1),  messaging  systems  (Defense 
Message  System2),  data  links  (such  as  the  Joint  Tactical  Integrated  Data  System,  Link-163), 
command  and  control  systems  (such  as  the  Global  Command  and  Control  System,  Maritime, 
GCCS-M4),  navigation  systems  (such  as  the  Navigation  Sensor  System  Interface5),  and  combat 
direction  systems  (such  as  Aegis  Command  and  Decision6).  Each  of  these  systems,  developed  at 
great  cost  over  many  years,  have  attractive  capabilities.  It  is  more  cost-effective  to  integrate  them 


1  A  Space  and  Naval  Warfare  Systems  Command  PMW-176  product 
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~  A  Space  and  Naval  Warfare  Systems  Command  PMW-166  product 
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A  Space  and  Naval  Warfare  Systems  Command  PMW-159  product 

4  A  Space  and  Naval  Warfare  Systems  Command  PMW-157  product 

5  A  Space  and  Naval  Warfare  Systems  Command  PMW-156  product 

6  A  Naval  Sea  Systems  Command  PMS-400  product 
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into  a  single  system  than  to  build  a  new  single  system.  Processes  such  as  “Horizontal  Integration” 
(a  SPAWAR  Systems  Command  initiative)  and  FORCEnet  (a  Chief  of  Naval  Operations 
initiative)  promise  to  unify  many  of  these  systems.  However,  unless  these  initiatives  offer  an 
integrated  set  of  operator  capabilities  and  a  single-system  perspective,  they  will  fall  short  of  the 
single,  integrated  BM/C4ISR/N  system  which  the  operator  needs. 

Multipurpose  Activity  Definitions  and  Interfaces  to  Support  Operational  Needs  (MADISON),  a 
proposed  operator-oriented  approach  to  BM/C4ISR/N,  can  offer  a  single-system  perspective. 
MADISON  can  provide  the  operator  a  mission-related,  activity-based  interface  to  the  resources 
he  needs  to  accomplish  his  mission.  Once  implemented,  MADISON  would  support  complex 
operations,  set  clear  requirements  and  metrics  for  interoperability,  unify  operator  training, 
improve  operator  effectiveness,  and  increase  resource  allocation  efficiency.  MADISON  is 
“operator-centric,”  to  position  the  operator  to  fight  the  battle  rather  than  fight  the  system. 

2.  Introduction  to  MADISON 

MADISON  is  derived  from  the  activities  an  operator  performs  to  carry  out  the  mission.  An 
activity  is  a  fully  or  partially-automated  operator  function  (e.g.,  engage  target  or  send  message). 
Activities,  represented  by  objects,  characterize  the  types  and  qualities  of  service  an  operator  can 
request.  The  aggregate  of  activities  represents  both  operator  capabilities  and  system 
requirements.  The  activity  class  is  defined  in  terms  of  general  attributes  -  including  type  of 
service,  quality  of  service,  operator  role,  and  activity  priority  -  and  methods,  including  service 
requests  and  session  control.  The  activity  class  includes  three  subclasses:  the  operational  subclass 
comprises  activities  which  directly  support  operational  requirements;  the  management  subclass 
comprises  activities  which  indirectly  support  operational  requirements  by  allowing  the  operator  to 
configure  and  control  resources  (e.g.,  update  policies,  and  distribute  keys);  and  the  readiness 
subclass  includes  activities  which  assess  resource  status  and  current  capability. 

Key  MADISON  design-time  system  goals  are  adaptability  and  testability;  operation-time  goals 
include  flexibility,  interoperability,  survivability,  and  utility.  Activities  can  be  used  to  define  and 
test  interoperability,  based  on  activity  specifications  of  data  exchanges.  MADISON  resource 
managers  can  use  dynamic  policies  (and  priority)  to  resolve  resource  contention,  and  use 
transaction  processing  to  prevent  deadlock.  The  general  MADISON  technical  approach, 
illustrated  in  Figurel,  incorporates  the  following  concepts. 

•  Activities  are  described  in  common  formats  and  accessed  in  a  common  way.  An  operator 
accesses  activities  through  an  operator  interface  tailored  to  him.  Each  activity  is,  in  general, 
available  to  all  operators  although  access  restrictions  may  be  imposed  by  policy  managers 
(shown  in  Figure  3),  based  on  security,  rank,  mission,  etc.  The  aggregate  of  activities 
represents  the  (automated)  operational  capability  available  to  operators. 

•  Activities  obtain  service  from  resources  -  a  resource  may  be  a  system,  a  data  distribution 
network,  a  database,  an  input/output  device,  etc.,  -  via  resource  interfaces.  Operators  have 
(virtual)  access  to  all  needed  resources  and,  in  general,  do  not  need  to  know  which  resources 
support  their  activities.  The  aggregate  of  possible  service  requests  from  activities  to  resources 


comprises  requirements  for  resources.  In  other  words,  the  formal  definition  of  activities 
(including  functionality,  performance,  formats,  etc.)  constitutes  a  high-level  specification  for 
resources  to  be  acquired  to  implement  those  activities. 

•  MADISON  resource  managers  (shown  in  Figure  3)  use  dynamic  policies  (and  priority)  to 
resolve  resource  contention,  and  use  transaction  processing  to  prevent  deadlock. 
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Figure  1.  MADISON  Architecture 


3.  Introduction  to  MADISON.COMMS 

MADISON  should  be  developed  step-by-step,  beginning  with  a  communications  segment.  This 
segment,  MADISON.COMMS,  would  comprise  communications-based  activities  to  support  the 
operator  directly  (operator-to-operator  communications)  and  indirectly  (operator-to-application 
and  application-to-application  communications). 

3.1  MADISON.COMMS  Architecture 

Figure  2  shows  the  MADISON.COMMS  Architecture.  For  simplicity,  a  single  operator  (0(i))  is 
shown.  In  addition  to  concepts  which  apply  to  the  MADISON  architecture,  note  the  following. 

•  0(i)  has  access  to  all  BM/C4ISR/N  activities,  separated  into  (1)  COMMS,  (2)  BM/C2ISR/N, 
and  (3)  Computing  (not  shown  -  implied  to  part  of  all  activities).  COMMS  activities  can  be 
requested  (directly)  by  an  operator  or  (indirectly)  by  BM/C2ISR/N  activities  (“applications”). 
The  operator  does  not,  in  general,  see  whether  or  not  a  BM/C2ISR/N  activity  is  directly 
supported  by  COMMS  activities. 
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Figure  2.  MADISON.COMMS  Architecture 

3.2  MADISON.COMMS  Activities 

Operational  activities  for  MADISON.COMMS  can  be  derived  from  Mission  Capability  Packages 
(MCPs,  now  under  development  in  the  US  Navy7)  and  from  current  operational  capabilities. 
These  are  examples  of  current  operational  activities:  send8,  receive,  log,  retrieve,  and  forward 
naval  message,  email,  or  track  report;  establish,  accept,  and  terminate  voice  or  data  connection-, 
initiate,  enter,  exit,  and  terminate  collaborative  planning  sessions  or  video  teleconferences; 
establish  and  disestablish  radio  emissions  control  (EMCON);  and  transfer  files,  data,  and  control 
messages  in  support  of  applications.  Configuration  management  activities  may  include  the 
following:  initialize  and  configure  system  or  network;  and  enter  and  update  policy  or  user  profile. 
Examples  of  readiness  assessment  services  include  request  and  accept  resource  status  report. 

These  research  issues  are  associated  with  MADISON.COMMS  activity  definition:  (1)  COMMS 
activities  must  comprise  a  complete  (covering  all  direct  and  indirect  communications  services 
required  by  operators)  and  internally  consistent  (minimally  redundant  and  mutually  supportive)  set 
(iteration  will  be  needed  to  address  this  issue  in  the  absence  of  a  well-defined  set  of  BM/C2ISR/N 
activities);  (2)  Qualities  of  service  (i.e.,  operator-requested  service  characteristics)  must  address 
security  and  performance  constraints  and  requirements  and  be  implementation-independent;  and 
(3)  Operator  role  and  activity  priority  must  be  expressed  such  that  they  can  be  used,  with  defined 
policies,  to  make  resource-allocation  decisions. 


7  Within  the  Office  of  the  Chief  of  Naval  Operations,  N-7 

8  Send  may  specify  a  single  addressee,  multicast,  or  broadcast 
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Figure  3  extends  the  MADISON.COMMS  architecture  to  include  a  Policy  Manager  and  a 
Resource  Manager,  both  critical  to  MADISON.  The  Policy  Manager  determines  resource-access 
rights  and  activity  priority  based  on  operator  role,  requested  or  default  priority,  activity  access 
restrictions,  security  constraints,  operator-access  rights,  and  doctrine.  The  Policy  Manager  may 
be  initialized  and  reconfigured  through  an  activity.  The  Resource  Manager  allocates  resources  to 
activities  based  on  these  criteria:  1)  resource  suitability,  the  ability  of  the  resource  to  deliver  the 
type  and  quality  of  service  requested  by  the  activity,  the  comparative  resource  cost  (ideally,  the 
least  capable  available  resource  that  can  meet  the  request  is  selected,  reserving  more  capable 
resources  for  more  demanding  jobs);  2)  resource  availability,  the  ability  of  the  resource  to  meet 
operational  constraints  (e.g.,  an  EMCON  activity  may  constrain  emissions),  status  (on  or  off, 
mode,  readiness,  in  use),  and  an  indication  of  whether  the  resource  can  be  pre-empted  by  a  higher 
priority  activity;  and  3)  activity  priority,  as  requested  by  the  operator  and  verified  by  the  Policy 
Manager  with  respect  to  the  user  profile  and  current  policies. 

3.3  MADISON.COMMS  Example  Activity 

Establish  Connection  (EC),  one  of  the  activities  suggested  in  Section  3.2,  supports  voice  and  data 
connections  (a  voice  connection  is  effectively  a  phone  call).  Envision  an  operator  at  a  console 
wearing  a  headset  with  a  microphone  (very  common  these  days);  to  initiate  his  connection,  the 
operator  “clicks  on”  the  EC  activity  which  offers  him  a  menu  screen  showing  options,  each  of 
which  can  be  bypassed  in  favor  of  a  default  (to  save  time).  The  first  option  might  be  the  type  of 
call,  e.g.,  voice  message,  voice  conversation,  voice  and  data  (graphics),  etc;  in  the  case  of  a 
message,  the  caller  might  request  an  acknowledgment  (of  receipt).  A  set  of  options  could  relate  to 
the  receiver(s)  of  the  call.  Receivers  might  be  designated  by  number,  name,  or  role,  or  from  a 


directory  (directories  of  receivers  and  phone  numbers  (or  IP  addresses)  would  be  dynamically 
updated).  Another  set  of  options  would  address  the  archiving  of  messages  and  conversations. 
Still  another  would  allow  rapid  retry  of  previously  requested  services. 

There  could  be  complementary  options  for  the  accept  connection  (AC)  activity,  including  modem 
commercial  services  such  as  caller  ID,  call-waiting  indications,  automatic  or  operator-activated 
call  forwarding,  and  accepting  callers  into  a  conversation  in-progress.  The  services  which  support 
the  EC  and  AC  activities  have  been  implemented  successfully  by  industry. 

4.  A  Look  at  the  Supply  Side 

If  we  view  MADISON. COMMS  activities  as  the  “demand  side”  of  communications  operations,  it 
is  reasonable  to  ask  whether  it  is  feasible  to  meet  these  demands.  The  Traffic  Flow  Engineering9 
(TFE)  project  at  SSC  San  Diego  [Otte,  2002]  addresses  the  issue  of  independent  communications 
systems  from  the  “supply  side”  and  promises  to  meet  many  of  the  requirements  imposed  by 
MADISON.COMMS  activities.  In  particular,  the  TFE  project  will  implement  some  or  all  of  these 
features:  “(a)  Automated  bandwidth  management  over  all  links  in  the  network;  (b)  Automated 
routing  of  tactical  data  over  a  heterogeneous  collection  of  naval  communications  systems;  (c) 
Quality  of  Sendee  techniques  to  ensure  guaranteed  latency  and  accuracy  of  tactical  data  over 
limited  bandwidth  links;  (d)  Information  assurance  capabilities  including  authentication, 
encryption  and  data  integrity  at  all  network  layers;  (e)  Convergence  of  data/voice/video  over 
Internet  Protocol  [IP]  networks;  and  (f)  Alternatives  to  legacy  IP  routing  such  as  latency-based 
routing  and  policy-based  routing.”  [Otte,  2002] 

The  TFE  project  defines  traffic-flow  engineering  as  “the  process  of  controlling  link  utilization 
through  advanced  policy,  classification,  priority,  and  path  selection  mechanisms.”  The  project 
goal  is  to  use  these  mechanisms  to  “optimize  information  exchange  by  controlling  the  flow  of 
information  and  the  utilization  of  data  links”  and  then  apply  the  results  “to  the  Naval  Battleforce 
Network10  (NBN).”  [Otte,  2002] 

“Policy  in  this  context  is  the  set  of  rules  that  govern  information  flow  throughout  the  network. 
Policies  are  used  to  determine  how  information  exchanges  are  supported  within  the  network. 
They  tie  together  a  number  of  traffic-flow  engineering  components  such  as  classification, 
prioritization  and  path  selection.  Policy  management  tools  permit  modification  of  communications 
policies  in  order  to  keep  pace  with  changing  objectives,  environments,  and  priorities.  In  the  NBN, 
policy  management  functions  may  be  distributed  among  centralized  network  operations  center 
activities  as  well  as  those  closest  to  the  line  of  fire.”  [Otte,  2002]  A  policy  manager  is  necessary  to 
implement  MADISON,  as  has  been  described. 

“Classification  is  the  process  of  identifying  the  packets  that  make  up  an  information  exchange. 
Classification  is  a  critical  component  of  traffic-flow  engineering  that  permits  the  special  treatment 
of  information  exchanges  and  flows  vice  packets.  Once  classified,  information  flows  are  provided 


9  Sponsored  by  the  Office  of  Naval  Research  (ONR  313) 

111  Part  of  the  Office  of  Naval  Research’s  Future  Naval  Capability  (FNC)  for  Knowledge  Superiority  and  Assurance 


the  prioritization  and  path- selection  capabilities  they  require.”  [Otte,  2002]  Under  MADISON, 
classification  would  be  inherited  from  an  activity  attribute. 

“Prioritization  is  simply  the  process  of  identifying  and  assigning  a  relative  level  of  importance  to 
information  exchanges.  Prioritization  is  also  needed  to  meet  the  differing  requirements  of  voice, 
video,  data,  and  mission-critical  data.”  [Otte,  2002]  Under  MADISON,  priority  would  be 
inherited  as  an  activity  attribute. 

“Path  selection  is  the  process  of  identifying  and  choosing  a  link  or  combination  of  links  to  a 
destination.  Legacy  routing  algorithms  perform  this  function.  Shortcomings  in  legacy  routing 
protocols  and  metrics  fail  to  address  mission-oriented  path  selection  requirements.  Traffic-flow 
engineering  goes  beyond  legacy  routing  by  providing  path  selection  based  upon  mission-centric 
criteria,  such  as  reliability,  latency,  security,  probability  of  intercept,  and  load.  It  also  provides 
advanced  load  balancing  and  load  distribution  capabilities.  Policy  Based  Routing  (PBR)  is  one 
example  of  the  advanced  path  selection  techniques  available.”  [Otte,  2002]  Path  selection  would 
be  hidden  from  MADISON. COMMS  activities. 

“As  an  investment  strategy,  the  Navy  has  migrated  many  of  its  communications  requirements  onto 
IP-based  networks.  As  a  result,  the  Navy  benefits  from  the  substantial  research,  development, 
and  capabilities  of  Internet  technologies.  The  need  to  converge  voice,  data  and  video  over  a 
common  infrastructure  is  now  a  popular  industry  trend.  Early  voice,  video  and  data  convergence 
efforts  are  underway  but  current  IP  network  implementations  do  not  accommodate  the  different 
traffic  types  well.  The  different  requirements  of  voice,  video  and  data  have  been  a  major 
stumbling  block  toward  successful  convergence  and  effective  communications  exchange.  This 
condition  has  prompted  significant  developments  in  traffic-flow  engineering  technologies. 

’’Historically,  the  Navy  utilized  a  dedicated  link  for  a  specific  information  exchange  requirement. 
More  recent  Navy  communications  architectures  promote  a  de-coupling  of  individual  links  and 
information  exchanges.  The  de-coupling  strategy  promotes  a  situation  in  which  multiple  links  are 
made  available  to  support  multiple  information  exchange  requirements. 

“Although  it  has  been  a  goal  of  Navy  architectures  for  quite  some  time,  legacy  router-based  IP 
networks  do  not  effectively  re-assign  information  flows  to  links  with  underutilized  or  idle 
capacity.  Deficiencies  in  current  implementations  of  routing  protocols,  routing  metrics  and  load¬ 
balancing  algorithms  fail  to  provide  this  capability.  In  current  networks,  some  links  remain  idle 
while  others  experience  significant  congestion.  Policy-based  routing  and  advanced  algorithms  that 
permit  load  balancing  across  unequal  links  offer  substantial  improvement. 

“A  side  effect  of  more  recent  Navy  architectures  is  that  individual  information  exchange  systems 
no  longer  have  exclusive  access  to  a  link.  These  systems  must  compete  with  each  other  for  the 
pool  of  available  assets.  In  this  environment,  the  system  may  perform  better  as  a  whole,  but  the 
ability  to  predict  the  performance  of  individual  information  exchanges  is  lost.  It  is  a  challenging 
situation  where  the  capacity  of  terrestrial  and  shipboard  networks  vastly  exceeds  that  found  in  the 
wireless  ship-to-ship  and  ship-to-shore  environment.  When  information  is  exchanged  across  the 
boundaries  between  those  terrestrial  and  shipboard  networks  and  the  wireless  ship-to-ship/shore 


networks,  the  transition  from  high-capacity  networks  to  low-capacity  network  systems  creates  a 
serious  bottleneck.  Contention  issues  routinely  prevent  or  significantly  delay  the  exchange  of 
mission-critical  data.  Information  exchange  requirements  of  naval  platforms  frequently  exceed 
link  capacity.  The  probability  of  this  is  highest  during  crisis  situations.  A  combination  of 
advanced  path  selection  techniques  and  prioritization  will  re-establish  predictable  information 
exchange  performance  and  optimize  communications  within  the  NBN. 

“In  the  NBN,  ship-to-ship  links  provided  by  airborne  platforms  are  used  to  augment  existing 
satellite  links  terminating  in  Network  Operations  Centers  (NOCs).  The  new  links  and  resultant 
paths  add  much-needed  capability  but  also  complicate  current  routing  architectures.  In  existing 
Naval  networks,  link  cost  (routing  metric)  is  the  mechanism  used  to  determine  path  selection; 
mission-centric  requirements  are  not  taken  into  account.  Policy-based  routing  and  more  advanced 
routing  protocols  permit  mission-centric  path  selection  based  upon  reliability,  latency,  and  load. 
Navy  IP-based  communications  systems  will  benefit  from  traffic  flow  engineering  technology  that 
improves  the  flow  of  information  through  oversubscribed  links  and  selects  optimal  paths 
throughout  multiple-link  systems. 

“The  technologies  discussed  above  represent  the  virtually  “off-the-shelf’  commodities  available 
for  system  integration  with  a  high  likelihood  of  success.  In  many  cases  the  technologies  and 
capabilities  discussed  above  exist  in  the  devices  planned  for  the  NBN  (e.g.,  the  next-generation 
ADNS  router,  Cisco  3600).  In  addition,  the  substantial  commercial  and  economic  motivation  for 
these  technologies  ensures  their  rapid  maturity  and  evolutionary  progress.”  The  TFE  project  is 
tracking  “industry  standards  and  technology  development  in  traffic  flow  engineering”  and 
monitoring  “vendor  product  developments  and  participate  in  the  Internet  Engineering  Task  Force 
(IETF)  and  related  conferences  such  as  the  Internet  Bandwidth  Management  Summit  (IBAND).” 
This  will  provide  information  as  to  the  current  state  of  the  art  and  give  insight  into  future 
developments.  These  are  areas  of  particular  interest:  “(a)  Policy  management;  (b)  Packet 
classification  techniques  and  the  effect  of  encryption;  (c)  IP  Precedence;  (d)  Differentiated 
Services  (Diff-Serv);  (e)  Integrated  Services  (Int-Serv);  (f)  Multi- Protocol  Label  Switching 
(MPLS);  (g)  Application-aware  networks;  (h)  Network-aware  applications;  (i)  Policy-Based 
Routing  (PBR);  and  (])  Secure  routing  updates  based  upon  MD5  authentication.”  [Otte,  2002] 

The  TFE  project  is  developing  “a  system-wide  architecture  for  the  deployment  of  traffic  flow 
engineering  technology  within  the  NBN.  The  architecture  will  permit  the  deployment  of  policies 
that  promote  End-to-End  IP  Quality  of  Service  (IP  QoS)  and  advanced  path  selection...  Key 
characteristics  of  the  system  include:  (a)  Adaptable  policies;  (b)  Predictable,  reliable  and  available 
information  exchanges;  and  (c)  Security.  Key  strategies  of  the  architecture  include  keeping 
intelligence  at  the  edges  of  the  network,  maintaining  scalability,  minimizing  complexity  and 
utilizing  cost  effective  technologies.”  [Otte,  2002]  A  link  between  the  TFE  project  and  the 
MADISON  concept  is  being  explored. 


5.  Example  Thread 


A  thread  follows  an  instantiated  activity  through  the  system  (in  this  case,  a  hypothetical  system). 
A  three-way  conversation  with  supporting  graphics  is  chosen  for  illustration  here.  The  software 
packages  shown  in  blue  in  figures  4-9  are  part  of  MADISON.  The  operator  supplies  the 
specifications  shown  in  yellow.  His  menu  selections  result  in  the  following  description. 

Activity:  Establish  Connection:  voice  connection  +  graphics  (data) 

Attribute:  Caller:  Operator  a  on  Platform  A  0(A(a)) 

Receivers:  Operator  b  on  platform  B  0(B(b)) 

Operator  c  on  platform  C  0(C(c)) 

Service:  Type:  Confirm  participants  (using  control  messages) 

Quality:  acknowledgment  required 

Attribute:  Priority  (requestor  range  =  1:30):  Requests  activity  priority  25 
Attribute:  Session:  Start  150800Z  SEP  02;  End  150900Z  SEP  02 
Service:  Type:  Establish  voice  connection 
Quality:  One  speaker  at  a  time 
Service:  Type:  Establish  data  connection 
Quality:  Speaker  sends  graphics 

To  begin  service,  the  Policy  Manager  first  must  confirm  that  the  requested  priority  is  available  to 
the  operator,  as  shown  in  Figure  4. 


0(A(a)),  0(B(b)),  0(C(c)) 
Priority  =  25 

Start  =  150800Z  MAR  02 
End  =  150900Z  MAR  02 


Time 


Part  of  MADISON 


Operator  Specification 


Figure  4.  Example  Thread  -  Confirm  Priority 

Figure  5  shows  the  Activity  Object  Session  Manager  sending  a  message,  over  a  path  selected  and 
designated  by  the  Resource  Manager,  to  confirm  participant  availability. 


]  Operator  Specification 


Figure  5.  Example  Thread  -  Confirm  Participants 


In  Figure  6,  the  Resource  Manager  attempts  to  establish  the  required  connections  to  accomplish 
the  requested  service. 


Figure  6:  Example  Thread  -  Confirm  B:C  Connection 


The  request  cannot  be  satisfied  as  submitted;  the  operator  is  offered  four  options  as  shown  in 
Figure  7. 


]  Operator  Specification 


Figure  7:  Example  Thread  -  Establish  A:B  and  A:C  Connections 


Once  the  session  has  actually  begun,  an  operator  must  push  the  talk  button  and  then  see  his  own 
talk  light  come  on  before  he  can  speak  (and  be  heard  by  the  other  operators);  this  was  part  of  the 
service  request.  This  service  is  managed  by  MADISON  as  shown  in  Figure  8. 


[  |  Part  of  MADISON  Operator  Specification 


0(B(b))  &  0(C(c))  talk  buttons  extinguished 

Figure  8:  Example  Thread  -  Conduct  Session  #1 

Figure  9  reminds  us  that  an  operator  whose  talk  light  is  lit  may  send  graphics  to  the  others. 


j  ]  Part  of  MADISON  Operator  Specification 


Figure  9:  Example  Thread  -  Conduct  Session  #2 

6.  Extending  MADISON.COMMS  Activities 

This  section  indicates  how  MADISON  activities,  which  extend  across  the  BM/C4ISR/N  domain, 
would  be  derived;  they  would  then  be  used  to  complete  the  set  of  MADISON.COMMS  activities. 
The  example  illustrates  how  MADISON  operator  activities,  were  derived  from  a  given  set  of 
missions  and  capabilities,  to  support  development  of  C4ISR  Concepts  for  Street-Fighter1 1 . 

6.1  Selecting  MADISON  Activities 

Mission  areas  and  capabilities  are  listed  below. 

•  Mine  Warfare:  Detection,  classification,  identification,  neutralization 

•  Anti-Submarine  Warfare:  Detection,  classification,  localization  &  track,  neutralization 

•  Special-Operations  Support:  Insertion,  extraction,  mission  support,  search  and  rescue 

•  Reconnaissance,  surveillance,  and  target  acquisition  :  Reconnaissance,  surveillance,  signals 
exploitation,  target  acquisition 

•  Precision  targeting:  Land  attack,  naval  surface  fire  support,  air  strike  support,  battle 
damage  assessment 

•  Surface  warfare:  Detection,  classification/identification,  area  denial,  engagement,  battle- 
damage  assessment 

•  Littoral  oceanography:  Bathymetry,  photogrammetry,  hydrography,  instrument/sources 
deployment 
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•  Electronic  attack:  Jamming,  spoofing,  deception 

•  Air  defense:  Search,  acquire,  track,  engage,  assess  kill/damage 

The  mission  areas  and  capabilities  were  first  rewritten  using  operator-action  verbs  (with  objects  in 
parentheses).  Note  the  reuse  of  verbs. 

•  Mine  Warfare:  Detect  (mine),  classify  (mine),  identify  (mine),  engage  (mine) 

•  Anti-Submarine  Warfare:  Detect  (sub),  classify  (sub),  localize  (sub),  create  (sub)  track, 
engage  (sub) 

•  Special- Operations  Support:  Insert  (sof),  extract  (sof),  support  (sof),  localize  (sof),  rescue 
(sof) 

•  Reconnaissance,  surveillance  and  target  acquisition:  Deploy  surveillance  assets,  sense, 
analyze  signals,  acquire  target 

•  Precision  targeting:  Engage  (Land  target  [using  various  options]),  assess  (battle  damage) 

•  Surface  warfare:  Detect  (surface  target),  classify  (surface  target),  identify  (surface  target), 
define  area,  engage  (surface  target),  assess  (battle  damage) 

•  Littoral  oceanography:  Analyze  (ocean  conditions  [using  various  options],  deploy 
(instrument/sources) 

•  Electronic  attack:  Jam  (radios,  sensors),  spoof  (radios,  sensors),  deceive  (radios,  sensors) 

•  Air  defense:  Search,  acquire,  track,  engage,  assess  kill/damage 


Based  on  the  above  partition,  a  matrix  (not  shown)  of  mission  areas  and  common  activities  was 
drawn.  Activities  that  were  shared  among  several  mission  areas  were  identified  for  formal 
definition;  an  activity  appearing  just  once  was  combined  with  a  similar  activity  (such  as  create 
(track)  and  track)  or  a  companion  activity  under  a  single  interface  (e.g.,  insert  and  extract  special 
operations,  or  jam,  spoof,  and  deceive).  Activity  renaming  followed  activity  combining:  for 
example,  sense  includes  detect  and  search;  classify  includes  identify;  engage  includes  acquire; 
track  includes  create  and  localize;  support  includes  insert,  extract,  and  rescue;  deploy  includes 
defend  area;  analyze  includes  assess;  and  do  EW  includes  jam,  spoof,  and  deceive.  After  a  few 
refinements,  the  table  in  Figure  10  resulted  to  show  seven  separate  (possible)  interfaces  and  eight 
operator  activities,  all  but  one  common  to  more  than  one  mission  area. 


Mission 

MW 

ASW 

SOF 

PT 

SurfW 

ElecA 

AD 

Activity 

Sense 

X 

X 

X 

X 

X 

X 

Classify 

X 

X 

X 

Track 

X 

X 

X 

X 

X 

Deploy 

X 

X 

X 

Support 

X 

Engage 

X 

X 

X 

X 

X 

Analyze 

X 

X 

X 

X 

X 

X 

Do  EW 

X 

X 

X 

Figure  10.  User  Activities  under  User  Interfaces 


6.2  Defining  Activity  Objects 


Once  defined  in  depth,  these  operator  activities  embody  the  capabilities  which  the  operators 
require  to  support  the  given  mission  areas  and  it  is  possible  to  build  the  objects  that  represent 
them.  These  objects  can  be  used  differently  depending  upon  the  mission  area.  The  activity  class 
is  defined  here  first  in  terms  of  sets  of  attributes  and  methods.  The  object  definition  can  be 
formalized  under  a  methodology  (e.g.,  Rational  Rose)  or  in  a  programming  language  (e.g.,  C++). 

•  Operator- activity  attributes 

o  Type:  Sense;  Classify;  Track;  Deploy;  Support;  Engage;  Analyze;  Do  EW 
o  Operator:  Name;  Role;  Authority 
o  Operator  interface:  Screens 
o  Time:  Initiation;  Response 
o  Supporting  nodes,  resources,  functions;  . . . 
o  Constraints:  Time;  Distance;  Resources 

o  Others:  Action  list;  Priority;  Status;  Alerts;  Contention;  Rules  of  Engagement;  ... 

•  Operator-activity  methods 

o  Create  activity  specification:  Include  Time,  Action  list,  Priority,  Supporting  Nodes 
o  Verify  executability:  Check  status,  alerts,  execution  issues 

o  Show  execution  issues:  Contention,  ROE,  Proximity  to  friendly  forces,  Constraints 
o  Initiate  activity 
o  Allocate  resources 
o  Manage  session 
o  Manage  alerts 
o  Process  user  output 
o  Process  external  input 
o  Close  session 

The  next  step  is  to  clarify  which  attributes  and  methods  apply  to  which  activities  and  under  which 
mission  areas.  The  somewhat  conflicting  goals  are  to  faithfully  support  each  mission  area  and 
activity  while  achieving  commonalities  wherever  possible. 

7.  Payoffs 

Developing  MADISON  will  yield  several  payoffs.  At  requirements  time,  MADISON  activities 
will  provide  a  missing  link  between  capabilities  (such  as  those  expressed  under  MCPs)  and 
BM/C4ISR/N  system  implementations  (such  as  those  described  for  the  TFE  project).  Formal 
definition  of  BM/C4ISR/N  activities  will  provide  the  theoretical  basis  for  a  single  operator 
interface  to  the  implementing  system(s);  the  aggregate  of  activities  will  represent  the  capability 
available  to  an  operator;  and,  the  activities  will  represent  BM/C4ISR/N  system  requirements. 
These  system  requirements  will  motivate  and  validate  efforts  such  as  the  TFE  project,  highlight 
the  items  of  highest  interest,  and  build  on  the  results  of  these  “supply  side”  efforts.  Formal  system 
requirements,  developed  and  owned  by  the  government,  will  be  visible  to  all  system  builders. 


At  design  time,  upgrades  to  the  general  infrastructure  will  be  integrated  and  tested  with  respect  to 
well-defined  interfaces  and  services  yielding  adaptability.  Activity  definitions  provide  formal 
specifications  of  what  activities  (and  implementing  resources)  must  accomplish  and  clarify 
necessary  system  services.  As  they  stabilize  and  are  made  widely  available,  activity  specifications 
become  visible  targets  for  implementers.  Competition  to  provide  implementation  improvements 
could  yield  long-term  cost  and  performance  gains.  Activities  can  only  work  if  system 
specifications  are  internally  consistent  and  provide  for  successful  resource  allocation  and  data 
transfer.  Interoperability  is  necessary  to  successful  activity  execution  and  can  be  tested,  activity 
by  activity;  this  means  that  interoperability  is  well-defined  and  verifiable.  Success  in  capturing 
common  features  across  multiple  activities  will  yield  software  reuse.  If  pursued  on  a  broad  basis, 
MADISON  can  provide  a  framework  for  integrating  systems  and  operations  across  the 
BM/C4ISR/N  domain.  At  test  and  evaluation  time,  the  activities  become  both  concept 
demonstration  and  assessment  points  and  system  test  and  evaluation  points. 

At  training  time,  operators  need  only  be  trained  on  one  system  (interface)  and  therefore  the 
training  and  rating  processes  can  be  simplified.  Since  activities  are  mission-related,  since 
commonality  will  lead  to  frequent  use,  and  since  operators  will  train  on  the  “real”  interface, 
operators  can  be  expected  to  become  very  familiar  with  their  activities.  Familiarity  should  bring 
about  operator  efficiency  during  training  (and  then  during  operations).  Activities  specified  with 
respect  to  mission,  rather  than  system  operation,  will  make  learning  the  system  and  learning  (to 
support)  the  mission  complementary.  A  single  interface  solves  the  problem  of  training  operators 
to  use  multiple  systems  and  to  use  the  “right  system  at  the  right  time,”  thereby  assuring  improved 
effectiveness  during  operations. 

At  operation  time,  MADISON  supports  operators  in  the  performance  of  their  mission,  rather  than 
challenges  their  ability  to  operate  the  system.  This  is  a  big  payoff,  like  allowing  a  race-car  driver 
to  focus  on  driving  while  his  sponsor  and  pit  crew  worry  about  tires,  engine,  fuel,  etc,  and  should 
provide  rapid  mission-related  response.  A  tailored  interface  provides  ease  of  use.  On  his  side  of 
that  interface,  the  tactical  operator  sees  operational  activities  -  formulated  as  types  and  qualities 
of  service  -  and  is  thus  shielded  from  implementing-system  details.  At  the  same  time,  technical 
users  have  access  to  management  and  readiness  activities  to  address  system  issues.  Operator- 
directed  activities  will  call  upon  implementing  resources  to  distribute  only  data  necessary  to 
operations  and  will  therefore  use  available  bandwidth  and  computing  power  efficiently. 
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